%reflection section dealing with questions: How did you plan to solve the problem? How did you plan the work in the group? What other methods did you try out? What did work/ did not work? Why? How did you end up with the current approach? How did you measure the performance and success during the process? How would you solve it if you were asked to do it again given what you know now?

\section{Reflection}
In order to give a solution to the problem we used two different approaches. The first one, which was presented for the milestone, came out spontaneously, and then, since it didn't give the proper results, it had to be changed.

This first approach could only find a solution for boards where a valid path would come out of pushing boxes into goals from their starting positions, not taking into account any movement that implied placing a box outside of a goal. We tried to find the shortest valid path from a box to an empty goal, for every possible box and goal configuration. The algorithm would end when finding a solution where every box would be in a goal. This way we could solve enough boards for the milestone but we wanted to improve using this as a starting point. 

Our first idea for improving was just to find the shortest path between one box and one goal, without checking if there were any boxes on this path. Then we would try to take all boxes out of this path. To verify if our strategy was accurate before writing any code, we tried to do cold runs of it on many online boards. Really soon we found out that this idea would not be successful.  For example we found the situation (Look at Figure \ref{pic/bad})
\begin{figure}[!htb]
\centering
\includegraphics[width = 0.3\textwidth]{pics/badExample}
\caption{Example for a Board that we couldn't have solved with our second approach}
\label{pic/bad}
\end{figure}
were there is a box that can't be removed out of the path, but there would be a valid path to put the red box in a goal if the first box is moved only one space.

As a result of this we realized that we had to take every possible path into account. But since this would result in a too large search tree, we needed to find efficient pruning techniques. Therefore we found some improvements explained in section \ref{app}. Most of the definitions of these techniques were found on the internet, nonetheless all of the implementation had to be deduced by ourselves. At this point we defined interfaces for every pruning function, so every person was able to deal with one of these improvements. This way we achieved maximal optimality in developing time, which left us a considerable amount of days to proceed with the tests. Even with the given interfaces we had to spend a lot of time to integrate all the implementations together before we could start to find bugs in the combined solution.

Nonetheless, in this first approach we checked for duplicate solutions by comparing the full string representation of the board. It was only after a help session that we could incorporate the hashing method, resulting now in maximum performance.

In order to make use of all the resources (human and physical) that we had in hand during the developing process, we defined in each stage all the classes and methods that had to be developed. These classes were designed and discussed. Afterwards, all the signatures for such were included in the source code with the proper documentation and were distributed equally among the group members. When the methods were done, we met to debug together.

In order to check if our solutions were giving the desirable results, we wrote a test script that would run the agent using the 100 boards defined in \url{dd2380.csc.kth.se} through port 5032. The agent was tested to solve the boards in 1 second, which, even though was shorter than the real testing time, it was good enough to give a quick performance measure.

If we had to solve the problem again, there are a few things we would do differently. First we would use from the beginning the approach that gave us the best results, and that is described in this report. Also, we would dedicate more time to designing the solution, in order to get an efficient approach before coding. Finally, we would try to design better pruning techniques that result in exploring less nodes with a very low computational cost.